Implementering av Web Security Headers: JavaScript Content Security Policy (CSP)

I dagens digitale landskap er websikkerhet avgjørende. Å beskytte nettstedet ditt og dets brukere mot ondsinnede angrep er ikke lenger valgfritt, men en nødvendighet. Cross-Site Scripting (XSS) er fortsatt en utbredt trussel, og et av de mest effektive forsvarene er å implementere en sterk Content Security Policy (CSP). Denne veiledningen fokuserer på å utnytte JavaScript til å administrere og distribuere CSP, og gir en dynamisk og fleksibel tilnærming for å sikre webapplikasjonene dine globalt.

Hva er Content Security Policy (CSP)?

Content Security Policy (CSP) er en HTTP-responsoverskrift som lar deg kontrollere ressursene brukeragenten (nettleseren) har lov til å laste inn for en gitt side. I hovedsak fungerer den som en hviteliste, og definerer opprinnelsene som skript, stilark, bilder, skrifter og andre ressurser kan lastes inn fra. Ved eksplisitt å definere disse kildene, kan du redusere angrepsoverflaten til nettstedet ditt betydelig, noe som gjør det mye vanskeligere for angripere å injisere ondsinnet kode og utføre XSS-angrep. Det er et viktig lag med forsvar i dybden.

Hvorfor bruke JavaScript for CSP-implementering?

Selv om CSP kan konfigureres direkte i webserverens konfigurasjon (f.eks. Apaches .htaccess eller Nginxs konfigurasjonsfil), tilbyr bruk av JavaScript flere fordeler, spesielt i komplekse eller dynamiske applikasjoner:

• Dynamisk policygenerering: JavaScript lar deg generere CSP-policyer dynamisk basert på brukerroller, applikasjonstilstand eller andre kjøretidsbetingelser. Dette er spesielt nyttig i single-page applikasjoner (SPA) eller applikasjoner som er sterkt avhengig av klient-side gjengivelse.
• Nonce-basert CSP: Bruk av nonces (kryptografisk tilfeldige, engangstokens) er en svært effektiv måte å sikre innebygde skript og stiler på. JavaScript kan generere disse nonces og legge dem til både CSP-overskriften og de innebygde skript/stil-taggene.
• Hash-basert CSP: For statiske innebygde skript eller stiler kan du bruke hashes til å hviteliste spesifikke kodebiter. JavaScript kan beregne disse hashene og inkludere dem i CSP-overskriften.
• Fleksibilitet og kontroll: JavaScript gir deg finkornet kontroll over CSP-overskriften, slik at du kan endre den fortløpende basert på spesifikke applikasjonsbehov.
• Feilsøking og rapportering: JavaScript kan brukes til å fange CSP-bruddrapporter og sende dem til en sentral loggingsserver for analyse, noe som hjelper deg med å identifisere og fikse sikkerhetsproblemer.

Sette opp din JavaScript CSP

Den generelle tilnærmingen innebærer å generere en CSP-overskriftstreng i JavaScript og deretter sette den aktuelle HTTP-responsoverskriften på serversiden (vanligvis via backend-rammeverket ditt). Vi skal se på spesifikke eksempler for forskjellige scenarier.

1. Generere Nonces

En nonce (tall brukt én gang) er en tilfeldig generert, unik verdi som brukes til å hviteliste spesifikke innebygde skript eller stiler. Slik kan du generere en nonce i JavaScript:

            function generateNonce() {
  const crypto = window.crypto || window.msCrypto; // For IE support
  if (!crypto || !crypto.getRandomValues) {
    // Fallback for older browsers without crypto API
    return Math.random().toString(36).substring(2, 15) + Math.random().toString(36).substring(2, 15);
  }
  const arr = new Uint32Array(1);
  crypto.getRandomValues(arr);
  return btoa(String.fromCharCode.apply(null, new Uint8Array(arr.buffer)));
}

const nonce = generateNonce();
console.log("Generated Nonce:", nonce);

            

              
                Copy
              
            
          

Denne kodebiten genererer en kryptografisk sikker nonce ved hjelp av nettleserens innebygde crypto API (hvis tilgjengelig) og faller tilbake til en mindre sikker metode hvis API-et ikke støttes. Den genererte nonce er deretter base64-kodet for bruk i CSP-overskriften.

2. Injisere Nonces i Innebygde Skript

Når du har en nonce, må du injisere den i både CSP-overskriften og <script> taggen:

HTML:

            <script nonce="YOUR_NONCE_HERE">
  // Your inline script code here
  console.log("Hello from inline script!");
</script>
            

              
                Copy
              
            
          

JavaScript (Backend):

            const nonce = generateNonce();
const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;

// Example using Node.js with Express:
app.use((req, res, next) => {
  res.setHeader('Content-Security-Policy', cspHeader);
  // Pass the nonce to the view or template engine
  res.locals.nonce = nonce;
  next();
});

            

              
                Copy
              
            
          

Viktige Merknader:

• Erstatt YOUR_NONCE_HERE i HTML med den faktiske genererte nonce. Dette gjøres ofte på serversiden ved hjelp av en malmotor. Eksemplet ovenfor illustrerer å sende nonce til malmotoren.
• script-src direktivet i CSP-overskriften inkluderer nå 'nonce-${nonce}', slik at skript med den samsvarende nonce kan kjøre.
• 'strict-dynamic' er lagt til `script-src` direktivet. Dette direktivet forteller nettleseren å stole på skript som er lastet inn av klarerte skript. Hvis en skripttagg har en gyldig nonce, vil ethvert skript den laster inn dynamisk (f.eks. ved hjelp av `document.createElement('script')`) også bli klarert. Dette reduserer behovet for å hviteliste mange individuelle domener og CDN URLer og forenkler CSP-vedlikehold betydelig.
• 'unsafe-inline' frarådes generelt når du bruker nonces, da det svekker CSP. Det er imidlertid inkludert her for demonstrasjonsformål og bør fjernes i produksjon. Fjern dette så snart du kan.

3. Generere Hashes for Innebygde Skript

For statiske innebygde skript som sjelden endres, kan du bruke hashes i stedet for nonces. En hash er et kryptografisk sammendrag av skriptets innhold. Hvis skriptets innhold endres, vil hashen endres, og nettleseren vil blokkere skriptet.

Beregne Hashen:

Du kan bruke online verktøy eller kommandolinjeverktøy som OpenSSL til å generere SHA256-hashen til det innebygde skriptet ditt. For eksempel:

            openssl dgst -sha256 -binary your_script.js | openssl base64
            

              
                Copy
              
            
          

Eksempel:

La oss si at det innebygde skriptet ditt er:

            <script>
  console.log("Hello from inline script!");
</script>
            

              
                Copy
              
            
          

SHA256-hashen til dette skriptet (uten <script> taggene) kan være:

            sha256-YOUR_HASH_HERE
            

              
                Copy
              
            
          

CSP Overskrift:

            const cspHeader = `default-src 'self'; script-src 'self' 'sha256-YOUR_HASH_HERE'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;
            

              
                Copy
              
            
          

Erstatt YOUR_HASH_HERE med den faktiske SHA256-hashen til skriptinnholdet ditt.

Viktige Hensyn for Hashes:

• Hashen må beregnes på det nøyaktige innholdet i skriptet, inkludert mellomrom. Eventuelle endringer i skriptet, selv et enkelt tegn, vil ugyldiggjøre hashen.
• Hashes er best egnet for statiske skript som sjelden endres. For dynamiske skript er nonces et bedre alternativ.

4. Sette CSP-Overskriften på Serveren

Det siste trinnet er å sette Content-Security-Policy HTTP-responsoverskriften på serveren din. Den nøyaktige metoden avhenger av din server-side teknologi.

Node.js med Express:

            app.use((req, res, next) => {
  const nonce = generateNonce();
  const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;
  res.setHeader('Content-Security-Policy', cspHeader);
  res.locals.nonce = nonce; // Make nonce available to templates
  next();
});
            

              
                Copy
              
            
          

Python med Flask:

            from flask import Flask, make_response, render_template, g
import os
import base64

app = Flask(__name__)

def generate_nonce():
    return base64.b64encode(os.urandom(16)).decode('utf-8')

@app.before_request
def before_request():
    g.nonce = generate_nonce()

@app.after_request
def after_request(response):
    csp = "default-src 'self'; script-src 'self' 'nonce-{nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests".format(nonce=g.nonce)
    response.headers['Content-Security-Policy'] = csp
    return response

@app.route('/')
def index():
    return render_template('index.html', nonce=g.nonce)

            

              
                Copy
              
            
          

PHP:

            <?php
function generateNonce() {
  return base64_encode(random_bytes(16));
}

$nonce = generateNonce();
header("Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-" . $nonce . "' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests");
?>
<!DOCTYPE html>
<html>
<head>
  <title>CSP Example</title>
</head>
<body>
  <script nonce="<?php echo htmlspecialchars($nonce, ENT_QUOTES, 'UTF-8'); ?>">
    console.log("Hello from inline script!");
  </script>
</body>
</html>
            

              
                Copy
              
            
          

Apache (.htaccess):

Selv om det ikke anbefales for dynamisk CSP, *kan* du sette en statisk CSP ved hjelp av .htaccess:

            <IfModule mod_headers.c>
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;"
</IfModule>
            

              
                Copy
              
            
          

Nginx:

            add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;";
            

              
                Copy
              
            
          

Viktige Merknader:

• Erstatt 'self' med de faktiske domenene du vil tillate at ressurser lastes inn fra.
• Vær ekstremt forsiktig når du bruker 'unsafe-inline' og 'unsafe-eval'. Disse direktivene svekker CSP betydelig og bør unngås når det er mulig.
• Bruk upgrade-insecure-requests for automatisk å oppgradere alle HTTP-forespørsler til HTTPS.
• Vurder å bruke report-uri eller report-to for å spesifisere et endepunkt for å motta CSP-bruddrapporter.

CSP Direktiver Forklart

CSP bruker direktiver for å spesifisere de tillatte kildene for forskjellige typer ressurser. Her er en kort oversikt over noen av de vanligste direktivene:

• default-src: Spesifiserer standardkilden for alle ressurser som ikke er eksplisitt dekket av andre direktiver.
• script-src: Spesifiserer de tillatte kildene for JavaScript.
• style-src: Spesifiserer de tillatte kildene for stilark.
• img-src: Spesifiserer de tillatte kildene for bilder.
• font-src: Spesifiserer de tillatte kildene for skrifter.
• media-src: Spesifiserer de tillatte kildene for lyd og video.
• object-src: Spesifiserer de tillatte kildene for plugins (f.eks. Flash). Generelt bør du sette dette til 'none' for å deaktivere plugins.
• frame-src: Spesifiserer de tillatte kildene for rammer og iframes.
• connect-src: Spesifiserer de tillatte kildene for XMLHttpRequest, WebSocket og EventSource-tilkoblinger.
• base-uri: Spesifiserer de tillatte base URIene for dokumentet.
• form-action: Spesifiserer de tillatte endepunktene for skjemainnsendinger.
• upgrade-insecure-requests: Instruerer brukeragenten til å behandle alle et nettsteds usikre URLer (de som serveres over HTTP) som om de har blitt erstattet med sikre URLer (de som serveres over HTTPS). Dette direktivet er ment for nettsteder som er fullstendig migrert til HTTPS.
• report-uri: Spesifiserer en URI som nettleseren skal sende rapporter om CSP-brudd til. Dette direktivet er utdatert til fordel for `report-to`.
• report-to: Spesifiserer et navngitt endepunkt som nettleseren skal sende rapporter om CSP-brudd til.

CSP Kildelist Nøkkelord

• 'self': Tillater ressurser fra samme opprinnelse (skjema, vert og port).
• 'none': Forbyr ressurser fra enhver opprinnelse.
• 'unsafe-inline': Tillater innebygde skript og stiler. Unngå dette når det er mulig.
• 'unsafe-eval': Tillater bruk av eval() og relaterte funksjoner. Unngå dette når det er mulig.
• 'strict-dynamic': Spesifiserer at tilliten som nettleseren gir et skript på siden på grunn av en medfølgende nonce eller hash, skal forplantes til skriptene som er lastet inn av det skriptet.
• 'data:': Tillater ressurser lastet inn via data: skjemaet (f.eks. innebygde bilder). Bruk med forsiktighet.
• 'mediastream:': Tillater ressurser lastet inn via mediastream: skjemaet.
• https:: Tillater ressurser lastet inn over HTTPS.
• http:: Tillater ressurser lastet inn over HTTP. Generelt frarådet.
• *: Tillater ressurser fra enhver opprinnelse. Unngå dette; det beseirer formålet med CSP.

CSP Bruddrapportering

CSP-bruddrapportering er avgjørende for å overvåke og feilsøke CSP-en din. Når en ressurs bryter CSP, kan nettleseren sende en rapport til en spesifisert URI.

Sette opp et Rapportendepunkt:

Du trenger et server-side endepunkt for å motta og behandle CSP-bruddrapporter. Rapporten sendes som en JSON-nyttelast.

Eksempel (Node.js med Express):

            app.post('/csp-report', (req, res) => {
  console.log('CSP Violation Report:', req.body);
  // Process the report (e.g., log to a file or database)
  res.status(204).end(); // Respond with a 204 No Content status
});
            

              
                Copy
              
            
          

Konfigurere report-uri eller report-to Direktiver:

Legg til report-uri eller `report-to` direktivet til din CSP-overskrift. `report-uri` er utdatert, så foretrekk å bruke `report-to`.

            const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests; report-to csp-endpoint;`;
            

              
                Copy
              
            
          

Du må også konfigurere et Reporting API-endepunkt ved hjelp av `Report-To` overskriften.

            Report-To: { "group": "csp-endpoint", "max_age": 10886400, "endpoints": [{"url": "/csp-report"}], "include_subdomains": true }
            

              
                Copy
              
            
          

Merk:

• `Report-To` overskriften må settes på hver forespørsel til serveren din, ellers kan nettleseren forkaste konfigurasjonen.
• `report-uri` er mindre sikker enn `report-to` fordi den ikke tillater TLS-kryptering av rapporten, og den er utdatert, så foretrekk å bruke `report-to`.

Eksempel CSP Bruddrapport (JSON):

            {
  "csp-report": {
    "document-uri": "https://example.com/page.html",
    "referrer": "",
    "violated-directive": "script-src 'self' 'nonce-YOUR_NONCE_HERE'",
    "effective-directive": "script-src",
    "original-policy": "default-src 'self'; script-src 'self' 'nonce-YOUR_NONCE_HERE'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests; report-uri /csp-report;",
    "blocked-uri": "https://evil.com/malicious.js",
    "status-code": 200,
    "script-sample": ""
  }
}
            

              
                Copy
              
            
          

Ved å analysere disse rapportene kan du identifisere og fikse CSP-brudd, og sikre at nettstedet ditt forblir sikkert.

Beste Praksiser for CSP-Implementering

• Start med en restriktiv policy: Begynn med en policy som bare tillater ressurser fra din egen opprinnelse og løsne den gradvis etter behov.
• Bruk nonces eller hashes for innebygde skript og stiler: Unngå å bruke 'unsafe-inline' når det er mulig.
• Bruk 'strict-dynamic' for å forenkle CSP-vedlikehold.
• Unngå å bruke 'unsafe-eval': Hvis du trenger å bruke eval(), bør du vurdere alternative tilnærminger.
• Bruk upgrade-insecure-requests: Oppgrader automatisk alle HTTP-forespørsler til HTTPS.
• Implementer CSP-bruddrapportering: Overvåk CSP-en din for brudd og fiks dem umiddelbart.
• Test CSP-en din grundig: Bruk nettleserens utviklerverktøy for å identifisere og løse eventuelle CSP-problemer.
• Bruk en CSP-validator: Online verktøy kan hjelpe deg med å validere CSP-overskriftssyntaksen din og identifisere potensielle problemer.
• Vurder å bruke et CSP-rammeverk eller -bibliotek: Flere rammeverk og biblioteker kan hjelpe deg med å forenkle CSP-implementering og -administrasjon.
• Gå gjennom CSP-en din regelmessig: Etter hvert som applikasjonen din utvikler seg, kan det hende at CSP-en din må oppdateres.
• Utdann teamet ditt: Forsikre deg om at utviklerne dine forstår CSP og dens betydning.
• Distribuer CSP i faser: Start med å distribuere CSP i rapport-bare modus for å overvåke brudd uten å blokkere ressurser. Når du er sikker på at policyen din er korrekt, kan du aktivere den i håndhevingsmodus.
• Dokumenter CSP-en din: Hold et register over CSP-policyen din og årsakene bak hvert direktiv.
• Vær oppmerksom på nettleserkompatibilitet: CSP-støtte varierer på tvers av forskjellige nettlesere. Test CSP-en din på forskjellige nettlesere for å sikre at den fungerer som forventet.
• Prioriter sikkerhet: CSP er et kraftig verktøy for å forbedre websikkerheten, men det er ikke en mirakelkur. Bruk den sammen med andre sikkerhetsmessige beste praksiser for å beskytte nettstedet ditt mot angrep.
• Vurder å bruke en Web Application Firewall (WAF): En WAF kan hjelpe deg med å håndheve CSP-policyer og beskytte nettstedet ditt mot andre typer angrep.

Vanlige Utfordringer ved CSP-Implementering

• Tredjepartsskript: Å identifisere og hviteliste alle domenene som kreves av tredjepartsskript kan være utfordrende. Bruk `strict-dynamic` der det er mulig.
• Innebygde stiler og hendelsesbehandlere: Å konvertere innebygde stiler og hendelsesbehandlere til eksterne stilark og JavaScript-filer kan være tidkrevende.
• Nettleserkompatibilitetsproblemer: CSP-støtte varierer på tvers av forskjellige nettlesere. Test CSP-en din på forskjellige nettlesere for å sikre at den fungerer som forventet.
• Vedlikeholdskostnader: Å holde CSP-en din oppdatert etter hvert som applikasjonen din utvikler seg kan være en utfordring.
• Ytelsespåvirkning: CSP kan introdusere en liten ytelsespåvirkning på grunn av behovet for å validere ressurser mot policyen.

Globale Hensyn for CSP

Når du implementerer CSP for et globalt publikum, bør du vurdere følgende:

• CDN-leverandører: Hvis du bruker CDNer, må du sørge for at du hvitelister de aktuelle CDN-domenene. Mange CDNer tilbyr regionale endepunkter; å bruke disse kan forbedre ytelsen for brukere i forskjellige geografiske områder.
• Språkspesifikke ressurser: Hvis nettstedet ditt støtter flere språk, må du sørge for at du hvitelister de nødvendige ressursene for hvert språk.
• Regionale forskrifter: Vær oppmerksom på eventuelle regionale forskrifter som kan påvirke CSP-kravene dine.
• Tilgjengelighet: Sørg for at CSP-en din ikke utilsiktet blokkerer ressurser som kreves for tilgjengelighetsfunksjoner.
• Testing på tvers av regioner: Test CSP-en din i forskjellige geografiske regioner for å sikre at den fungerer som forventet for alle brukere.

Konklusjon

Implementering av en robust Content Security Policy (CSP) er et avgjørende skritt i å sikre webapplikasjonene dine mot XSS-angrep og andre trusler. Ved å utnytte JavaScript til å dynamisk generere og administrere CSP-en din, kan du oppnå et høyere nivå av fleksibilitet og kontroll, og sikre at nettstedet ditt forblir sikkert og beskyttet i dagens stadig utviklende trusselbilde. Husk å følge beste praksiser, test CSP-en din grundig og overvåk den kontinuerlig for brudd. Sikker koding, forsvar i dybden og en godt implementert CSP er nøkkelen til å gi sikker surfing for et globalt publikum.